\subsection{Results}
\label{test:video:results}
A summary of the results are plotted in Figure \ref{fig:test_video} where the effects of varying values of $\boldsymbol \Gamma$ is shown. On each plot the horizontal-axis represents the packet loss probability, thus indicating a decreasing link quality. The vertical-axis shows the number of decoded frames pr. total frames, thus the amount of received decodable video frames at the sink.
 
% JEPPE PILLER HER
%The scenario is of course a multi sink broadcast set-up, where each nodes link quality is unique.

From Figures \ref{fig:testvideo30} through \ref{fig:testvideo70} it is seen that increasing packet loss leads to a rapid decrease in frames decoded from \ac{L2}. For tests with $\mathbf{\Gamma}_1$ higher than 0.35 it is seen that not all \ac{L2} frames can be decoded, even without packet loss. This is not completely in line with the needed overhead calculations in Section \ref{sec:testvideo_calc}, presented in \ref{tab:videotestoverhead}, and the added shared overhead. All tests up to $\mathbf{\Gamma}_1=0.45$ should be able to decode. Though, the testing overhead calculations is a mean function, meaning some generations require less overhead than specified, some more. This causes some generations not being able to decode although the overhead is larger than specified in Table \ref{tab:videotestoverhead}.

As $\boldsymbol \Gamma_1$ tends to zero \ac{UEP} becomes \ac{EEP}. This effect is seen when comparing Figures \ref{fig:testvideo30} through \ref{fig:testvideo70}. The \ac{EEP} curve is identical in all plots. As $\boldsymbol \Gamma_1$ increases, \ac{L2} will require an increasing amount of overhead in order to be able to decode everything, contrary to \ac{L1} where most data can be decoded alongside with \ac{EEP}.


% Increase gamma 1 to expand layer 1

The amount of \ac{L1} frames decoded at higher rate of packet loss increases for higher values of $\mathbf{\Gamma}_1$, as presented in Figure \ref{fig:test_video}, though with less \ac{L2} frames decoded as a consequence. This illustrates one of the trade-offs in \ac{UEP} compared to \ac{EEP}. The gain in \ac{UEP} is that the \ac{L1} frames will be preserved at higher rates of packet loss, and that this data is usable. This ensures that at least a poor quality video is decodable, opposed to the \ac{EEP} case where no video is decodable. 

As the packet loss increases, \ac{L2} will decrease in a somewhat linear manner, reaching zero along with \ac{EEP}. This is intuitively correct as both \ac{L2} and \ac{EEP} contains the entire generation.

The result of \ac{UEP} is a more graceful degradation of the video quality beyond 30\% packet loss, when compared to \ac{EEP}. This can be favorable if several receivers with various link quality listens on the same broadcasted video stream. The nodes with the worst link quality might be able to decode a good part of the I-frames, while the nodes with better connections may receive a better, or even error free video stream.

%Expanding layer 1 will also expand the span where each individual sinks packet loss probability may lie, in order to decode at least layer 1\fixme{JK: Jeg forstår ikke denne sætning}. This span is the result of the trade-off with \ac{UEP}, the span ensures that at least a poor quality video is decodable oppose to no video at all with \ac{EEP}. The span results in layer 1 sustains a more graceful degradation beyond a packet loss of 30 \%, when compared to \ac{EEP} \fixme{JK: Jeg har faktisk svært ved at forstå hele afsnittet}

%As the packet loss probability \ac{L2} will decrease in a somewhat linear manner, reaching zero along with \ac{EEP}. This is intuitively correct as both \ac{L2} and \ac{EEP} contains the entire generation.
Using \ac{UEP} would be inefficient if all sinks have link quality good enough for \ac{EEP} as this would reduce overhead, thus reduce channel load. However this requires all sinks to have a reverse channel to deliver feedback to the source, and as state in Section \ref{prestudy:errororrectingcodes:feedback} this is not beneficial in a broadcast scenario.

\begin{figure} \centering
\vspace{-0.5cm}
\subfloat[Test \# 1: $\boldsymbol \Gamma_1=0.30$.]{\label{fig:testvideo30}\includegraphics[width=0.450\textwidth]{figs/testvideo30.eps}} 
\subfloat[Test \# 2: $\boldsymbol \Gamma_1=0.35$.]{\label{fig:testvideo35}\includegraphics[width=0.450\textwidth]{figs/testvideo35.eps}}
\\
\subfloat[Test \# 3: $\boldsymbol \Gamma_1=0.40$.]{\label{fig:testvideo40}\includegraphics[width=0.45\textwidth]{figs/testvideo40.eps}}
\subfloat[Test \# 4: $\boldsymbol \Gamma_1=0.45$.]{\label{fig:testvideo45}\includegraphics[width=0.45\textwidth]{figs/testvideo45.eps}}
\\
\subfloat[Test \# 5: $\boldsymbol \Gamma_1=0.50$.]{\label{fig:testvideo50}\includegraphics[width=0.45\textwidth]{figs/testvideo50.eps}}
\subfloat[Test \# 6: $\boldsymbol \Gamma_1=0.70$.]{\label{fig:testvideo70}\includegraphics[width=0.45\textwidth]{figs/testvideo70.eps}}
\caption{Test of implemented software with actual video data. The test setup configurations used are shown in Table \ref{tab:videotestsetup}. Results are calculated with 40\% shared overhead. Please note that Layer 2 contains the same data as an \ac{EEP} generation, while Layer 1 mainly contains I-frames.}
\label{fig:test_video}
\end{figure}

Due to the large size of the I-frames, the amount of frames stored in \ac{L1} is very limited. Therefore, the amount of frames decoded when using the \ac{UEP} methods might not speak in favour of \ac{UEP}. Though, if \ac{UEP} is applied to \ac{SVC}, which is designed to scale proportionally with the amount of information received, better video quality may be achieved when the receiver is only able to partially decode the data.



